• ' f 




NAVAL POSTGRADUATE SCHOOL 
Monterey, California 




THESIS 



ARCHITECTURAL GUIDELINES FOR MULTIMEDIA 
AND HYPERMEDIA DATA INTERCHANGE: 
COMPUTER AIDED ACQUISITION AND LOGISTICS 
SUPPORT/CONCURRENT ENGINEERING (CALS/CE) 
AND ELECTRONIC COMMERCE/ELECTRONIC DATA 
INTERCHANGE (EC/EDI) 

by 

Alexander D. Korzyk 
SEPTEMBER 1991 

Thesis Advisor: Myung Suh 



Approved for public release: Distribution is unlimited 

T257827 



Unclassified 

ECURITY CLASSIFICATION OF THIS PAGE 



REPORT DOCUMENTATION PAGE 



Form Approved 
OMB No 0704 0188 



la REPORT SECURITY CLASSIFICATION 

Unclassified 



lb. RESTRICTIVE MARKINGS 



2a. SECURITY CLASSIFICATION AUTHORITY 



2b. DECLASSIFICATION/DOWNGRADING SCHEDULE 



3 DISTRIBUTION/AVAILABILITY OF REPORT 

Approved for public release: Distribution is 
unlimited 



4. PERFORMING ORGANIZATION REPORT NUMBER(S) 



5 MONITORING ORGANIZATION REPORT NUMBER(S) 



6a. NAME OF PERFORMING ORGANIZATION 

Naval Postgraduate School 



6b. OFFICE SYMBOL 
(if applicable ^ ^ 



7a. NAME OF MONITORING ORGANIZATION 

Naval Postgraduate School 



6c. ADDRESS (City, State and ZIP Code) 

Monterey, CA 93943-5000 



7b. ADDRESS (City, State, and ZIP Code) 

Monterey, CA 93943-5000 



8a NAME OF FUNDING/SPONSORING 
ORGANIZATION 



8b OFFICE SYMBOL 
(If applicable) 



9. PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER 



8c. ADDRESS (City, State, and ZIP Code ) 



10 SOURCE OF FUNDING NUMBER 



PROGRAM 


PROJECT 


TASK 


WORK UNIT 


ELEMENT NO. 


NO. 


NO 


ACCESSION NO. 



1 1 . TITLE (Include Security Classification) 

Architectural Guidelines for Multimedia and Hypermedia Data Interchange: Computer Aided Acquisition and Logistics Support/Concurrent 
Engineering (CALS/CE) and Electronic Commerce/Electronic Data Interchange (EC/EDI) 



12. PERSONAL AUTHORS 

ALEXANDER D. KORZYK 



13a. TYPE OF REPORT 

Master s Thesis 



13b. TIME COVERED 


14 DATE OF REPORT (Year, Month, Day) 


15. PAGE COUNT 


FROM TO 


SEPTEMBER 1991 


107 



16. SUPPLEMENTARY NOTATION 



The views expressed are those of the author and do not reflect the official policy or position of 
the Department of Defense or the U.S. Government 



17. COSAT I CODES 



FIELD 



GROUP 



SUB-GROUP 



18. SUBJECT TERMS (Continue on reverse if necessary and idenvfy by block numbers) 

multimedia, hypermedia, CALS, CE, EC, EDI, DSI, 
X.400, X.435, paperless office 



19. ABSTRACT (Continue on reverse if necessary and identify by block numbers) 

This study proposes the best strategy to integrate information systems to effectively support 
several common Department of Defense initiatives, in line with Corporate Information 
Management and Total Quality Management principles. This research examines Computer- 
aided Acquisition and Logistics Support/Concurrent Engineering, Electronic 
Commerce/Electronic Data Interchange, Modernization of Defense Logistics Standard System, 
and the Defense Information System. The study proposes an interchange architecture on top 
of the OSI-compliant Defense Information System, which serves as a telecommunications 
infrastructure, for multimedia and hypermedia data interchange. This interchange architecture 
is necessary to successfully implement the functions and applications of DOD activities. 



20. DISTRIBUTION AVAILABILITY OF ABSTRACT 

XX UNCLASSIFIED/UNLIMITED SAME AS RPT 



DTIC USERS 



21. ABSTIWCT SECURITY CLASSIFICATION 

unclassified 



22a NAME OF RESPONSIBLE INDIVIDUAL 

Myung Suh 



22b TELEPHONE (Include Area Code) 

(408) 646-2637 



22c OFFICE SYMBOL 

AS/Su 



>D Form 1473, JUN 86 



Previous editions are obsolete. 

S/N 0102-LF-014-6603 



SECURITY CLASSIFICATION OF THIS PAGE 

Unclassified 



Approved for public release: Distribution is unlimited 



Architectural Guidelines for Multimedia and Hypermedia Data Interchange: 
Computer Aided Acquisition and Logistics Support/Concurrent Engineering 
(CALS/CE) and Electronic Commerce/Electronic Data Interchange (EC/EDI) 

by 

Alexander D. Korzyk 
Major, United States Army 
M.B.A., Florida Institute of Technology, 1985 
B.S.E., United States Military Academy, 1978 

Submitted in partial fulfillment of the 
requirements for the degree of 

MASTER OF SCIENCE 
IN INFORMATION SYSTEMS 

from the 

NAVAL POSTGRADUATE SCHOOL 



SEPTEMBER 1991 



ABSTRACT 



This study proposes the best strategy to integrate information systems to 
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Defense Information System. The study proposes an interchange architecture 
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I. INTRODUCTION 



Department of Defense (DOD) is promoting Total Quality Management 
(TQM) at the executive levels. However, as in the case of implementing 
Electronic Commerce/Electronic Data Interchange (EC/EDI) and Computer 
Aided Acquisition and Logistics Support/Concurrent Engineering (CALS/CE), 
there is a need to practice more TQM on a more formal basis. As Verity (1991) 
suggests, customers have automated virtually all the easy tasks they can find: 
payroll, financial accounting, inventory, etc. In DOD, even these easy tasks 
have not been done efficiently or effectively. Instead of automating the way 
DOD had done business for many years, DOD should have re-engineered the 
process, and then applied computer technology to the system. A Corporate 
Information Management (CIM) principle states that you must first simplify 
the business process before you computerize. Technology should not be applied 
until you are sure the organization can implement the changes, according to 
Strassman (June, 1991). DOD is not alone in having failed to re-engineer 
processes before automating them over the last two decades. Re-engineering 
of the processes is what the high-level executives have been searching for 
during the past 20 years. After re-engineering the entire way daily business 
is done, productivity may go up or sales may increase. According to Verity 
(1991), the re-engineering market will reach $15 billion in 1995. In the past 
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DOD has let technology be the driver instead of the workflow. It is not too late 
to rethink EC/EDI and CALS/CE in the much bigger environment instead of 
treating them as other islands of automation that have persisted for the last 
decade. DOD should impose the CIM principles on the initiatives discussed in 
this research immediately by speeding up the adoption of Open Systems 
Interconnection (OSI) and the introduction of multi-level security into the 
information systems standards, according to Strassman (June, 1991). 

When we look at the diversity of the DOD and the number of initiatives 
started, you cannot help but wonder how anyone can understand what is going 
on with information resources. This research will attempt to define the 
underlying infrastructures to effectively support several of DOD’s initiatives, 
especially CALS/CE, EC/EDI, MODELS, and DIS. All businesses actually rely 
on various types of information which are conveyed on documents. The 
multimedia presentations one can see from high technology computer 
companies demonstrating their products are just a taste of what is to come in 
the future. 

Business processes have evolved over the past 30 years but have only just 
begun to be re-engineered as technology matures. Unfortunately, DOD is 
already several years behind industry and with current policies will fall even 
further behind unless some strategic changes are made soon and strictly 
enforced. 
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This research examines these common DOD initiatives and tries to show 



how an interchange architecture conforming to OSI can provide an effective 
telecommunications infrastructure and define multimedia and hypermedia 
interchange standards to support necessary functions and applications for 
EC/EDI, CALS/CE, and MODELS. The primary research questions this study 
are: 



• What is the best strategy in terms of standards to successfully implement 
EC/EDI and CALS/CE? 

• What protocols are the best to use in order to communicate with industry 
and within DOD? 

• Is it feasible to use DDN for multimedia data interchange or is ISDN 
necessary? 

• Is the intelligent gateway solution feasible or is there a better platform 
or solution? 
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II. CALS/CE: TECHNICAL AND MULTIMEDIA 
DATA INTERCHANGE 



A. BACKGROUND 

1. Paperless Environment 

The dream of a paperless office surfaced nearly 20 years ago. 
Information system professionals tried their best to progress towards the 
paperless office with the technology they had available. The dream has never 
died but keeps eluding business and the Government. CALS/CE is the 
integration of manufacturing, engineering, and logistics support to a near 
paperless environment. The reduction of the life cycle cost of weapon systems 
through competitive parts production and reduced lead times can be effected 
by implementing CALS. Maintaining configuration data in near real-time will 
provide support of the major weapon systems like the Seawolf submarine and 
B2 stealth bomber. 

2. Policy Direction 

Completely isolated islands of automation need to be interfaced to 
form integrated systems. The changes made by CALS will involve enterprise 
wide models/architecture of computing and communications. The re- 
engineering of workflows will involve changing both the DOD and business 
environment. This research consolidates information resource initiatives such 



u 



4 



as CIM, CALS, EC/EDI, and MODELS in the spirit of Corporate Information 
Management and Total Quality Management. Although the islands of 
automation are to be integrated in the weapons systems area, many CALS 
proponents were creating another island of automation called CALS/CE. Many 
more individuals, both in business and DOD, realize now that CALS is 
applicable to much more than acquisition and procurement. Expanding global 
markets and shrinking DOD markets have reduced the need for new weapon 
systems and called for more modification and maintenance of old weapon 
systems. Strassman (July, 1991) states that the Technical Integration Manager 
of the DISA will develop and maintain technical and data architectures which 
impact the Functional Integration Manager and ensure technical integration 
throughout functional areas with the technical and data architectures. 
Unfortunately, CALS/CE technical and data architectures are being developed, 
maintained and integrated without regards to other similar DOD initiatives. 
What began as CALS several years ago should now be looked upon as 
Computer-Aided Acquisition Logistics Support Migration Systems and not just 
CALS. 

3. CALS/CE Objectives 

The objectives of CALS/CE from Dobey (1989) are: 

• Develop and test data interchange and access standards to create a 
shared information environment 

• Provide high risk technology development funding 
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• Establish contract requirements and incentives for industry 

• DOD-wide implementation 

B. REQUIREMENTS 

1. MIL-HDBK-59 CALS Program Implementation Guide (1988) 

The Handbook (1988) gives "guidance to personnel responsible for the 
acquisition and use of weapon system technical data to assist in transitioning 
from paper-intensive processes to digital data delivery and access." There are 
two methods for digital delivery or digital access to the IWSDB: data transfers 
are currently done by magnetic tape or DDN. Generic guidance is given in the 
following application areas: 1) technical manuals; 2) engineering drawings, 
specifications, and book-form drawings; 3) LSAR (Logistic support analysis 
record data MIL-STD-1388-2B); and 4) training materials. The Handbook also 
addresses database and telecommunications security. 

2. Contractor Integrated Technical Information Service (CITIS) 

A critical portion of CALS is the establishment of distributed data 
bases between DOD and contractors. DOD will have access to contractor 
generated and contractor maintained databases of weapon system data. 

3. Joint Uniformed Services Technical Information System 
(JUSTIS) 

DOD will also have distributed databases storing, retrieving, and 
processing technical data. The Interactive Electronic Technical Manual (IETM), 
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with multimedia (or hypermedia) capability, will have access to these 
engineering drawing repositories. The drawings will extensively use CAD to 
integrate design and design analysis processes. Such technical information 
integration will be called JUSTIS (Joint Uniformed Services Technical 
information system). It will provide the infrastructure for managing technical 
manual data in all formats in the integrated weapon system data base. 

4. CE/PIE (Concurrent Engineering/Parallel 
Integrated Engineering) 

This is a process for continuously refining and defining the product 
by considering all elements of product life cycle management. The last phase 
of Life Cycle Management uses the Total Quality Management techniques of 
continously reviewing the process according to DOD Directive 7920.1 (1988). 
This helps insure a successful product. 

C. DATA INTERCHANGE STANDARDS AND PROTOCOLS 

CALS standardization includes three areas that will not be examined 
here: functional requirements, data management and access standards, and 
application guidance. The two areas that will be discussed in detail are data 
interchange standards and communication protocols. Data interchange 
standards are common rules for digital interchange of technical information 
and will be the focus of CALS Phase I. 
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1. MIL-STD-1840A Automated Interchange of 
Technical Information (1987) 

This is the master document for all military specifications through 
which the CALS standards will be published. The original MIL-STD-1840 was 
published by the Air Force in 1986 and the MIL-STD-1840 A by NIST in 1987 
through an interagency agreement. It is updated annually. The main technical 
concept is that of a digital envelope which organizes files of digital data into 
a deliverable document. A document can be complex. For example, technical 
manuals contain SGML text files, raster and CGM illustration files. The 
original MIL-STD-1840 contained the IGES, SGML, RASTER, and CGM which 
have since developed into standards by themselves. 

2. MIL-D-28000 Initial Graphics Exchange Specification 
Computer Aided Design (IGES CAD) Vector Graphics 

This standard defines the digital representation for communication 

of product data between dissimilar computer aided design systems. It is also 

known as ANSI Y14.26M. It defines the interchange format between CAD 

systems into four classes: 1) engineering drafting Class II; 2) mechanical three 

dimension models Class IV; 3) electronic circuit design Class III; and 4) 

technical publication illustrations Class I. The graphics are represented in 

ASCII format and already supported by 30 CAD vendors. The Navy EDMICS 

(Engineering Data Management Information and Control System), Air Force 

EDCARS (Engineering Data Computer Assisted Retrieval System), Army 

DSREDS (Digital Storage and Retrieval Engineering Data System) are current 
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projects (Smith, 1990). This standard is developing into the Product Data 
Exchange Specification (PDES). 

3. MIL-D-28001 Standard Generalized Markup Language (SGML) 

This standard is for automated publishing of page oriented text, 
meets markup requirements, and generic style specification for electronic 
printed output and exchange of text and hypertext. SGML is critical for 
hypermedia data interchange. The standard is also known as ISO 8879 
Information Processing-text and Office Systems-Standardized Markup 
Language (SGML). Other standards used with SGML are: DSSSL (Document 
Style Semantics and Specification Language) for output specifications; SPDL 
(Standard Page Definition Language) for data delivery; and FOSI (Formatting 
output specification instance). SGML is used for printing technical 
publications, composition processing functions, defining output specifications 
of typographic tags and format rules, and displaying the composed document. 

4. MIL-R-28002 GROUP 4 RASTER Facsimile 

This standard sets requirements for raster graphics representation 
in binary format or bit map graphics that have been compressed to reduce file 
size and transmission time. There are two types of raster graphics. In Type I 
(untiled, which is FIPS 150), the default mode is 200 pels per inch with Group 
4 encoding. 
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Type II (tiled) defines a tile as a rectangular region in a layout object 
in which all such regions have the same dimensions. No part of any tile 
overlaps any other tile. Group 4 raster permits compression and decompression 
in parallel on the drawing tiles or portion of the drawing tiles. The division of 
tiles can be individually processed to reduce the size of the transmission line 
and reduce terminal storage requirements. Type II is used for oversize 
documents such as large engineering drawings. 

5. MIL-D-28003 Computer Graphics Metafile (CGM) 

This standard is for the digital representation for communication of 
illustration data between high resolution graphics workstations. Unlike IGES, 
which is for CAT) workstations, it is based on line segments. The metafile 
includes allowable output primitives and attributes used to compose 
illustrations. The standard is also known as ANSI X3.122, FIPS 128, and ISO 
8632. This standard is for picture descriptions and illustrations in technical 
manuals. 

6. Communication Protocols 
a. Short Term 

In the short run, DDN will be used for transmission of CALS 
data. Most large drawings, which are stored on magnetic media such as tapes, 
floppies, or optical disks, will have to be compressed as much as possible to 
reduce file size and transmission times. Unfortunately most engineering 
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drawings are very large, and even with compression techniques still require 
several hours to transmit over DDN. 

b. Long Term 

According to Lycas (1989), CALS data will be interchanged using 
OSI protocols such as X.400 Message Handling System (MHS) and File 
Transfer Access and Management (FTAM). Chapter IV will discuss all 
protocols in detail. The underlying network will have to be a broadband 
switched network, not a traditional packet- switched network like DDN. 

D. NEW INFRASTRUCTURES 

1. CALS Test Network (CTN) 

The CTN was created to demonstrate CALS standards and test their 
effectiveness under the U.S. Air Force Logistic Command leadership. It is a 
joint DOD-Industry program for applications testing, prototype computer 
product conformance testing, and prototype data acceptance testing. The 
testing is done in laboratories and uses controlled live data. The standards 
discussed previously will be required for contractors, subcontractors, and 
vendors desiring to do business in the Industrial-Military Complex. Selected 
defense contractors, laboratories, the Army CALS testbed, and other 
Government sites make up the CTN. 
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2. Industrial Networks 



General Motors Corporation developed a global data communications 
network internally and has thousands of trading partners internationally. GM 
has always been one of the major driving forces in the Industrial-Military 
Complex. GM developed its command and control network from a baseline 
much like DOD developed DDN, but GM has committed many more resources 
into networking than DOD. Connectivity between DOD and large industrial 
networks has the potential to totally change the way business is done. 

3. FTS-2000 and ISDN 

DeLaura (1986) first analyzed data communication requirements for 
CALS. DeLaura (1987) concluded that DDN could not provide adequate 
support for the very large documents that CALS contractors and Government 
users would transmit. Payne (1990) further confirmed that bulk transfers could 
not be adequately performed using DDN. CALS data, being multimedia and 
hypermedia information, requires very high speed which must include FDDI 
and ISDN. 

4. CALS Operational Resource Information System (CORIS) 

CORIS, like CTN, is based on a distributed database that logically 
integrates engineering, logistics, and manufacturing databases. A data 
communications infrastructure other than DDN will be necessary to implement 
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CALS. A CALS Information Manager will provide directory services, data 
dictionaries, and indexing. (CALS Exposition, 1990) 

E. OTHER STANDARDS FOR CALS 

Several other international standards will be implemented in CALS Phase 
II. Most of the following are application specific: 

• EDIF (Electronic Design Interchange Format) for integrated circuit 
design. 

• ODA/ODIF (Office Document Architecture/Office Document Interchange 
Format) for presentation and layout. 

• SPDL (Standard Page Description Language) for image delivery of 
technical publications. 

• IRDS (Information Resources Dictionary System) for data elements. 

• SQL (Structured Query Language) for data access. 

• STEP (Standard for the Exchange of Product model data ISO TC 
184/SC4. 

F. SUMMARY 

The strategy of implementing CALS must be reexamined. This research 
has shown many of the current standards that have paved the way for 
industry and defense during the initial years of the CALS initiative. It is 
imperative that DOD use CALS to prevent existing systems from becoming 
islands of automation and integrate them into the Corporate Information 
Management systems as soon as possible. In fact, Strassman (June, 1991) 
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states that one of needed actions in speeding up the business process redesign 
of different functional processes is to impose CIM principles on existing 
systems. 
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III. EC/EDI ELECTRONIC COMMERCE/ELECTRONIC 
DATA INTERCHANGE 



A. BACKGROUND 
1. EDI Definition 

EDI is the computer to computer transmission of transactions 
primarily between external organizations computers in a format agreed upon 
by all trading partners. EDI is used as a means of eliminating the mail lag 
time into a matter of minutes to speed electronic commerce. Industry has used 
EDI for direct deliveries and just-in-time inventory techniques for several 
years. Organizations will not really benefit from EDI until it is integrated 
internally into the entire organization structure. 

Businesses use many types of transactions in their day to day 
operations to buy and sell goods and services from each other. The volume of 
Government business necessitates EDI, especially for small purchases. There 
were 12 million actions under $25,000 for FY90 according to Drake (1991). The 
acquisition and procurement system can use EC/EDI to send solicitations, 
awards, invoices, payments, delivery orders, contract accounting, etc. 
Transactions must conform to standards agreed upon by all trading partners 
because many forms of business documents exist in the business environment. 
DOD should consider evolving toward publicly available transactions so that 
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DOD may trade with all trading partners conforming to the ANSI X12 
standard. EDI formats define all possible fields, arrangement, and use. For 
example, ANSI X12 has defined the EDI transaction set for CALS data. 

MODELS addresses the DOD internal transaction processing. 
MODELS began in 1984 as a modernization of the DLSS (Defense Logistics 
Standards Systems). DOD revised MODELS transactions to become more like 
EDI syntax. 

Deputy Secretary of Defense Taft directed that DOD make maximum 
use of EDI for the paperless process of all business related transactions in May 
1988. Assistant Secretary of Defense (Production and Logistics) received 
responsibility for establishing guidance that will result in "..acceptance of EDI 
as the normal way of doing business with DOD by the early 1990s." The 
Assistant Secretary of Defense (P&L) designated the DLA (Defense Logistics 
Agency) as DOD’s Executive Agent for EDI and Data Protection. However, the 
entire excecutive agent procedure may change as a result of Corporate 
Information Management Reviews. In fact, Strassman (July, 1991) states that 
DISA will manage DOD-wide standards for information technologies and 
architecture in November 1990, Defense Management Report Decision 941, 
Implementation of EDI in DOD proposed milestones and a level of investment 
for EDI. 
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2. EC Definition 



Electronic Commerce is the integration of EDI, E-mail, bulletin 
boards, EFT, and similar techniques into an electronically based system for all 
DOD business functions to include government procurements and acquistion, 
payment, supply management, transportation base operations, contract 
administration, maintenance, and fuels. EC will put in place necessary 
systems, capabilities, and procedures that will fundamentally alter the 
business processes and daily operations from a paper intensive environment 
to a nearly paperless environment. CIM systems data standards and 
architectures must be developed rapidly and applied to EC before much further 
work is done according to Strassman (July, 1991). 

EC will rely on subsystems which will resemble many of the CALS 
subsystems. According to Drake (1991) the first subsystem will be an electronic 
market consisting of an electronic information broker, electronic classifed ads 
and advertising, electronic product and corporate profiles, and electronic 
common bulletin boards. The second subsystem will be an integrated 
distributed database with an interorganizational database and electronic report 
programs. The third subsystem will use EDI transaction sets for accessing and 
ordering and exchanging technical data. 



17 



B. REQUIREMENTS 



EC/EDI has many requirements that this research will examine together 
with the CALS/CE requirements to form a basis for multimedia data 
interchange. 

1. DLA Tasks 

The Electronic Commerce: A Strategic Plan for DOD (1990) specifies 
the tasks for DLA as follows: 



• Use established industry transaction standards, readily accessible 
technology, and commercially available products and services. 

• Develop and maintain implementation guidelines, establish support 
agreements, and provide configuration management translation software. 

• Provide common-user support for all DOD activities, including central 
directories and PLUS (Protection of Logistics Unclassified/Sensitive) 
initiatives. 

• Establish pilot applications for testing new Electronic Commerce concepts 
and products. 

• Participate in industry standard committees. 

• Provide a "single face to industry" on all EDI and PLUS activities. 

• Establish a nucleus of expertise to promote and aid early implementation 
of Electronic Commerce. 

• Accessability to proven, cost-effective, and standardized Electronic 
Commerce software, hardware, and communications, and accessability to 
clear, standard guidance on implementing Electronic Commerce. 

• Effective, knowledgeable representation in national and international 
standards development processes. 

• Dynamic, highly competent focal point on all matters related to EC. 
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• Automate the generation, processing, coordination, distribution, and 
reconciliation of every business transaction, from requistioning to base 
operations, throughout the DOD without need for hard-copy media. 

2. Business and Technical Data 

EC will provide prospective business offerors the business and 
technical data needed to make decisions and to prepare cost estimates. 
Businesses may transmit engineering drawings and specifications 
electronically when the procurement requires a shortened solicitation cycle. 
This research will show how most businesses may eventually transmit EDI 
transactions and accompanying data files in an E-mail envelope (X.435) to 
vendors in the electronic directory service (X.500). 

3. Interactive EDI 

Interactive EDI provides the mechanism for trading partners’ 
applications to communicate in a direct on-line manner beyond that of fast 
batch communications, according to the X12C Subcommittee (1991). 

a. Definition 

I-EDI is the ability for two computing devices to exchange X12 
information in a direct, conversational, and negotiable mode. Under batch EDI, 
transactions are transferred in an asynchronous mode going the other way. 
The transaction one partners sent is not synchronized with the transaction. 
However a transaction is very likely to be in response to previous transaction 
going the other way. Fast batch retains the communication connection in 
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anticipation of a transaction being returned by a partner in response to 
another partner. I-EDI contains blocks of EDI data in a peer-to-peer session 
performing the translation function between each peer’s application. 

b. Benefits 

Benefits of the interactive approach depend on the ability of the 
user to act quickly. The extent to which the trading partner is automated, the 
greater the reduction in connection time. The best case would be an interactive 
user agent that would react to results of searches on predefined rules rather 
than wait for human reaction. During multi-level searches I-EDI lets the user 
start from a previous point so that the search process does not need to start 
from the beginning again. 

4. Document Translation System Requirements 

a. EDI Translation Software 

EDI translation software reformats application data into an 
acceptable EDI standard format, as defined by X12. EDI standards change 
every six months and the means to update these easily is by maintaining 
translation tables separately from the applications. Vendors for most EDI 
software provide translation table updates to keep the system current. Generic 
interface files between the corporate applications and EDI software need 
customization for the specific user and can be customized for more than one 
user. The actual translation process modules may perform the integration of 
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1) the raw data; 2) trading partner information, and 3) the standards tables 
into a formatted EDI transmission ready to pass to the communication 
software. 

b. Data Mapping 

Data Mapping is essential to the successful operation of the EDI 
applications. Data mapping is required at the interface between EDI 
translation software and applications. A small translator which prints out a 
paper copy for action and accepts input from a keyboard can be the foot in the 
door for starting EDI, with a manual data mapping. The small translator can 
become integrated at a later time with the corporate database. Data mapping 
maps values between an intermediate flat file generated by EDI translation 
software and the appropriate locations in the database. The ultimate goal is 
application-to-application EDI in which data mapping is integrated in the 
initial design of the database or corporate information system. This will only 
be possible by using the CIM principle of providing interoperable vendor- 
independent systems assembled from standard components with distributed 
databases. 

c. EDI software alternatives 

DOD can make or buy EDI software. The Lawrence Livermore 
National Labs has developed Ascent software in cooperation with Control Data 
Corporation. This software is now offered on an U.S. Air Force contract as off- 
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the-shelf software. Many vendors have developed off-the-shelf EDI software 
which DOD could use by simply deciding on parameters for the fields. The off- 
the-shelf software allows a user to create his own transaction. Finally, value 
added network or third party networks support EDI gateways to multivendor 
platforms of trading partners throughout the world. These VANs are much 
more capable than only using one type of vendor software because the 
translation process is performed by the VAN. VANs are one of the most 
popular methods-approximately 25% of all EDI users use VANs, according to 
Drake (1991). 

d. EDI hardware alternatives 

Microcomputer stand-alone systems are usually used by a small 
company with a small amount of data, or by an EDI system not integrated 
with the applications. The cost of an adequate PC 286 AT compatible is now 
approximately $700; 2400 baud modem $100; 24-pin dot matrix printer $250; 
communication software $100; and EDI translation software $400-1000. So the 
total cost of an adequate system can be approximately $2,000-2,500 depending 
on the type of EDI software purchased. 

Microcomputer interfaces with outside communications, contain 
EDI translation software and can have direct hardwire interfaces with a 
mainframe. A mainframe receives all EDI data through one communication 
port in the communication processor and processes the raw data. Using the 
mainframe provides greater growth potential as EDI committments increase. 
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e. EDI Communications Options 



(1) Direct, point-to-point connection. This option was used 
initially until more companies began using EDI. When multiple trading 
partners exist establishing and maintaining many secure communication 
channel connections among them greatly increase costs. 

(2) Value Added Networks (VAN). Value added networks 
address the cost issues of a point-to-point connection by minimizing 
compatibility issues, scheduling problems, and providing control of the 
environment. Costs vary depending on the network, volume of transactions, 
and services used by the trading partners. VANs provide the following: 

• Store and forward services in which mailboxes store inbound transactions 
for the recipient. 

• Compliance checking services to determine if transactions are formatted 
as agreed upon by the trading partners. 

• Translation/conversion services into the format agreed upon by the 
trading partners. 

• Interconnection services to allow customers to deal with trading partners 
in other networks through gateways. 

f. EDI Implementation Problems 

Several problems may affect the implementation of EDI: 

• Using proprietary formats instead of international or national standards. 
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• Promising more than you can deliver. EDI is very limited in scope at this 
time. 

• Prescribing EDI as a do all. 

• Converting existing systems to EDI without analyzing the process or re- 
engineering following CIM principles and TQM methods. 

5. Electronic Contracting 

According to Drake (1991) EDI in procurement should be one of the 
first functional areas within the Federal Government to greatly benefit from 
EDI in a very short period of time. 

a. EDI/EFT 

General Electric (GE) Information Systems provide a large 
portion of EDI/EFT services for DOD. Payments from 66 payment offices to 10 
different GE businesses totalled $8 Billion in 1990, according to the Electronic 
Contracting Conference (1990). Of the $8 Billion, GE electronically collected $3 
Billion and provided electronic remittance advice on an additional $3 Billion. 
The major trading partners are the Defense Contract Administration Service 
Payment Centers and Kirtland Air Force Base. GE used ANSI standards not 
consistent with existing DOD EDI efforts. 

b. Paperless Contracting 

The goal of electronic contracting is to integrate paperless 
processing to include wordprocessing, spreadsheets, databases, expert systems, 
and EDI at the contract specialist’s desk. The main hurdles for paperless 
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processing are the efficient processing of multimedia data, digital signature 
and multi-level security. A digital signature is a symbol, generated through 
electronic means to verify the sender’s identity and the integrity of the 
information received from the sender. It may represent a person or 
organization. GSA has accepted digital signatures which use Public Key 
Encryption (PKE) as legally binding, according to the InfoSec Conference 
(1991). 

Networking is essential to successfully provide connectivity between 
contract offices and the customers. The contract office receives the procurement 
request from the customer and creates an electronic file folder placed in an 
electronic filing cabinet. A decision support system which is menu driven will 
serve as the procurement process guide to follow. Coordination with technical 
representatives, legal counsel, small business specialists, and with the 
customer will occur through EDI and E-mail. 

EDI applications in the Federal Government are few compared to 
numerous commercial applications. Two current EDI applications are: 1) 
Defense General Supply Center’s Paperless Ordering Placement System; and 
2) GSA Federal Supply Service use of purchase orders. Their main objectives 
are to eliminate duplication of work, speed up the procurement process, and 
eliminate paper. 

Expert systems should assist the contract manager in preparing the 
solicitation, evaluating the proposals, advising about regulations, source 
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selection, contract selection, and warranty analysis. Electronic contracting also 
assists the program manager in generating the acquistion package 
documentation, tracking a purchase request through the process, accessing 
acquistion regulations, and utilizing acquisition planning tools. Paperless 
contracting is nearly possible with the integration of contracting subsystems 
over networks using EDI. 

C. STANDARDS AND STRATEGY 

Different standards in the U.S. compared to the international standards 
may cause some difficulty in worldwide enterprises. 

1. ANSI X12 

The ANSI ASC (Accredited Standards Committee) X12 was chartered 
in 1979 to develop uniform standards for inter-industry electronic interchange 
of business transactions. X12 operates under the procedures of ANSI with the 
subcommittees listed in the Appendix. The ANSI ASC full committee has a 
membership of approximately 500 members who vote on issues. The ASC has 
a formal process for drafting standards for trial use. This process includes the 
following: 1) planning phase; 2) development phase; and 3) ASC X12 review 
and approval phase. 
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a. X12 Transmission Concept 



(1) Data Segments. Each X12 message consists of data 
segments, data elements, and a transmission envelope to form a transaction 
set. A data segment begins with its identification code, is followed by a specific 
sequence of mandatory and optional segments, and ends with a segment 
terminator character. Data segments must be selected from the X12 Data 
Segment Directory which specifies the make up of each transaction set by data 
segment. Each data segment consists of a sequence of data elements of variable 
length separated by a separator character. Data elements are classifed as 
identifiers, numeric, decimal, character, string, date, time, and binary found 
in the X12 Data Element Dictionary. See Figure 1. 

(2) EDI Envelope. An envelope contains a transaction set 
header which identifies the type of transaction set and a trailer which contains 
information verifying the number of segments in the transaction set. Similar 
type transaction sets may be transmitted as one functional group in a single 
envelope. 

(3) X12 Infrastructure. According to the X12 Information 
Manual (1991), the X12 standard consists of basic functions to make up a 
standard operating procedure and format which consists of the following: 

• Start and end validation. 

• Sender and destination identification. 
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• Senders control number. 

• Separators and terminators. 

• Data set identification. 

• Time and date stamp. 

• Exchange message count. 

• Telecommunications protocol interfaces. 
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Value added networks. 



• OfT-the-shelf applications software. 

b. X12 Standard 

The X12 standard consists of four main parts (Sokol, 1989). The 
X12.3 Data Element Dictionary specifies the name, description, type, and 
minimum/maximum lengths of each data element. The X12.5 defines 
Interchange Control Structures which is the EDI envelope. The X12.6 
Application Control Structures which are the formal descriptions of the EDI 
architecture. The X12.22 Segment Directory defines segments which are lists 
of related data elements. 

2. UN/EDIFACT United Nations For Administration Commerce 
and Transport 

X12 is the most prevalent standard in the U.S. However, some 
industries have found X12 inefficient. Some want additional fields while others 
would like to delete extra fields unnecessary for their industry. Even though 
the intra-industry committees have tried to address special needs, a strong 
international support developed for an international standard. A few United 
Nations projects to unite all standards around the world exist. The most 
popular worldwide standard is EDIFACT. DOD has adopted X12 as the EDI 
standard but supports the convergence of XI 2 with EDIFACT. 
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3. CALS MIL-STD-1840A Data Through Transaction Set 841 



a. The X12 Transaction Set 841 

The "Specification/Technical Information Transaction Set" 
merges Transaction set 839 Technical Information and 841 Specifications 
together according to Saltman (1990). ASC X12 added a special Government 
segment for CALS to use MIL-STD-1840A in 1989. The process described in 
Subsection C.l resulted in a 1989 ballot vote and again in 1990 by ASC X12. 
Currently, the X12 Procedure Review Board approved 841 as a draft standard. 

b. File Restructuring 

File restructuring of an 1840A includes the declaration file in the 
header area and the data files in the detail area. Multiple files forming a single 
document would allow repetition of detailed data. The trailer area will be used 
for verification and authentication. 

c. Government (GOV) Segment 

The GOV segment added to the 841 transaction set consists of 
three main data elements: (1) The item description qualifier which if coded MS 
means that the following data elements contain a record of the declaration file 
or the header of data files based on 1840A; (2) The record/file qualifier which 
contains the name of the record in the declaration file; and (3) The record 
format data which contains codes such as T2 for two text files, Q2 for two 
IGES files, and C2 for two CGM files in the transmitted document. 
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Saltman (1990) proposes that a total of 10 GOV segments will 
be in 841. The records not provided in the GOV segment (1,2,6, 9, and 13) will 
not be transmitted. Five additional GOV segments must be added and the data 
repeated along with the record names to transmit them. 

d. Transaction Set 

Data mapping of MIL-STD-1840A records to transaction set 841 
segments exist for IGES, Raster, CGM, PDL, gray scale, and special words 
files. Each transmitted document uses its own 841 transaction set which 
follows the one before. The envelope around one or more transaction sets in 
sequence consists of the functional group header, GS, and the functional group 
trailer, GE. The outer envelope outside the start of the first functional group 
and the end of the last functional group consists of the Interchange Control 
Header, ISA, and Interchange Control Trailer, IEA, according to Saltman 
(1990). 

e. Data Types for 841 

The types of technical data which wall require 841 are: 

• Engineering, quality, and test specifications. 

• Design analysis and review packages. 

• Technical proposals and support packages. 

• Product definition data. 



31 



• Technical orders and manuals. 

• Electrical and mechanical interface documents. 

f. Interim Solution 

The X12 841 transaction set is an interim solution because 
transmission costs are very high due to excessive overhead. A successor to the 
X12 841 transaction set will be the X.435 standard which is discussed in detail 
in Chapter IV. C. It will allow E-mail messages to carry EDI data, CAD/CAM 
data, and text data in the same envelope. It can separate these different data 
types and still organize the electronic message into body parts which makes 
it less expensive to process. Many of these compound documents may be over 
one gigabyte in length. 

4. Electronic Commerce: A Strategic Plan for DOD 

DLA proposed a very high level implementation plan with very long 
completion dates for the following implementation activities: (DLA, 1990). 

a. Business case preparation 

This justified the return on investment for EC. 

b. Implementing authority development 

DLA prepared memorandums for Secretary of Defense Offices 
which gave official support to EC initiative. 
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c. Implementation Baseline 

DLA compiled a list of all DOD components with on-going EDI 
projects. This was done to identify any duplication of effort, share experiences 
with other components, and prevent further duplication. 

d. Identification and Removal of Impediments 

DLA reviewed all regulations and statutes to identify 
impediments to the use of Electronic Commerce. They then developed a plan 
of action and schedule to remove the obstacles 

e. Implementation Guidelines Development 

DLA prepared standards, rules, and conventions for EDI between 
DOD and trading partners. 

f. Operational Concepts Development 

DLA prepared operational concepts for the following functional 
areas because they offered greater return on investment than other areas: 

• Finance Centers 

• Procurement and Contract Administration 

• Transportation 

• Supply Management 

• Maintenance 

• Fuels 

• Base Operations 



33 



g. Configuration of Research and Development Network 

DLA formed the Electronic Commerce Experimental Network to 

test new translation software, hardware, data communications, data security 
techniques, and other technological advances to enhance the EC program. 

h. Installation of Pilot Applications 

DLA is in the process of selecting pilot applications from the 
functional areas in Section f above to develop and implement in a real-world 
environment. 

i. Preparation of Data Dictionary 

DLA is in the process of preparing and publishing an EC data 
dictionary based on the Logistics Data Resource Management System, ANSI 
X12, and EDIFACT data dictionaries to insure the use of standard data 
elements. 

j. Development of Translation Software 

DLA is investigating the possibility of buying a translation 
software package off-the-shelf or developing it in- house after determining 
DOD’s translation software requirements. 

k. Procurement of Hardware 

DLA is surveying the market to determine what computer 
hardware will best meet EC users needs and will publish a preferred products 
list. 
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Z. Development of Communications Plan 

DLA is designing a communication network for EC which must 
determine the type of protocols and standards to use. This research will help 
DLA determine the best strategy to follow. 

m. Development of Security Plan 

DLA is researching how to incorporate multi-level security and 
manage the crytographic keys required for the systems. 

n. Development of Small Business Plan 

As part of the developing plan DLA conducted a small business 
fair in Dayton, Ohio, in April 1991 and demonstrated the Government 
Acquisition Through Electronic Commerce (GATEC) EDI project sponsored by 
the Wright Patterson Contracting Center. One of the first functional areas in 
which a very high ROI is expected is procurements under $25,000. Small 
businesses are big providers of products and goods for small procurements. 

o. Formulation of Marketing and Training Plans 

DLA is developing training materials on EC and is also releasing 
official articles on the DOD EC program for publication in Government and 
industry trade journals. 



35 



D. OBSERVATIONS 



1. EC/EDI Increases Competition 

All interested parties can receive notices of all opportunities and have 
access to the solicitation electronically if they have computers and EDI 
software. The Government increases the amount of the market which has a 
chance to look at the solicitation. Small businesses may use EDI with PCs. 
However, only EDI translation software is readily available and only a few 
business software packages provide EDI capability. CIM initiatives in 
procurement and contract payment should be integrated with EC techniques. 
CIM should establish a target date for all DOD transactions to use EDI based 
on commercially available software. 

2. EC/EDI Changes The Way We Do Business 

The main goal of EC is to achieve end-to-end paperless commerce. EC 
facilitates just-in-time inventory, direct vendor delivery, and use of 
nondevelopmental items. The biggest cost saver is the elimination of large 
stockpiles. 

3. Types of Procurements 

Indefinite Delivery Contracts (IDC) and Basic Ordering Agreements 
(BOA) have become a very popular means for rapid purchase requirements. 
IDCs attract greater market interest because the size of the solicitation may 
be larger than normal. For example, Desktop III and Desktop IV 
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microcomputer contracts allow any DOD agency to order computers from the 
contract. The IDC is completed with the assumption that the maximum order 
limit probably will not be reached. Invitation For Bid (IFB) contracts could also 
give a good ROI, but the volume compared to IDCs and BOAs is much lower. 

4. Electronic Bulletin Boards 

Electronic bulletin boards used to publicize contract actions, 
integrated vendor databases, and third party information brokers should be 
part of the procurement environment. An electronic CBD (Commerce Business 
Daily) divided by amount and type of supply would require less than half the 
time when compared to the hard copy CBD item to appear to the public 
(Drake, 1991). One format of the bulletin board would be X12 and the other in 
plaintext. Vendors could respond with EDI transactions to the DOD address 
in the CBD. One copy of the bulletin board could be only in the DOD 
environment and another copy on a commercial bulletin board because of 
security reasons. The commercial bulletin board could be managed by a 
contractor according to government regulations as a master copy. 

If the industrial infrastructure exists, then a distributed multi-vendor 
database could reside on a commercial mainframe accessed through a gateway. 
A request for quote for particular items from a DOD user to a vendor could be 
a query to the database thru the gateway. The need for a multi-level secure 
database exists for certain procurements. Oracle, Inc. for example provides a 
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trusted database. These same considerations are present in the CALS 
initiative. 

5. Industrial EDI Base 

DOD should build upon the large installed base of EDI software in 
the private sector to easily access DOD. FTS2000 would provide access to the 
private DOD wide area network. Autodin and the messaging part of DDN will 
be replaced by the year 2000 with DIS. DOD networks should become linked 
with Prodigy, CompuServe, Telenet, and Tymnet to provide wide access to all 
firms. 

a. Information Superhighways 

The information superhighway systems will be essential 
infrastructures for commerce and defense. The interstate superhighways will 
consist of individual statewide systems, metropolitan area beltways, with 
access to individuals and companies no matter where the location. 
Interchanges will be crucial to successful information transport particularly for 
traffic flow and accidents thru electronic gateways. DOD may make a strategic 
error if they choose not to use the industrial base interstate system and 
continue to use the military base system (DDN). Industrial information 
superhighways will provide the large links necessary for compound documents 
routine travel (FTS 2000). The US air transport system provides ultra fast long 
distance transport of small packages or bundles of information. Similarly, an 
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electronic messaging system for small bundles from point to point will be part 
of the information superhighway system. This information superhighway, in 
fact, has become global with the installation of fiber optic cables across the 
Atlantic and Pacific Oceans. DOD must recognize that the cost of maintaining 
and supporting a military infrastructure which tries to duplicate the industrial 
infrastructure is already cost prohibitive and will become more so. The 
duplication of the industrial infrastructure on a global scale would be futile. 
The Air Force has already had cost overruns while operating the Worldwide 
Military Command and Control Systems. 

b. EDI X12 For Document Translation. 

DOD should use X12 because it is a North American standard 
and most of DOD’s business contracts are within the United States. However, 
over half of the private sector does not use X12. But all vendors wishing to do 
business with DOD will have to purchase XI 2 software because DOD adopted 
X12 as the DOD standard. DOD’s internal formats in the DLSS are being 
updated to nearly X12 in the MODELS program because of some unique labels 
and contents of DOD fields. If no X12 field exists for DOD unique information, 
it can be placed in an optional field and still retain its format. DOD will 
develop X12 implementation guidelines so that VANs can offer X12 translation 
service with those particular DOD parameters. 
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6. EDI Network Architectures 



Several EDI network architectures are available to exchange 
information between DOD and the 300,000 plus vendors currently doing 
business with DOD (Drake, 1991). 

Mixed media such as a diskette or magnetic tape could be mailed 
between trading partners and only requires a standard format. 

Users could dialup via a modem and establish a dedicated link for 
the duration of the session. If the same EDI software resides on both 
computers no translation is necessary. If there is different E-mail software, 
then the electronic messaging standard X.400 could create an envelope around 
the X12 transactions with addressing information. The new standard X.435 
approved in June 1991, called PEDI, retains the EDI identification within the 
message header. This allows the routing of the EDI message without the need 
to check the contents of the message between various E-mail systems. 

E-mail with mailboxes provided by the trading partner computer or 
by a VAN would require the sender to place the message in the receiver’s 
mailbox and be notified at a later time that the receiver retrieved it. Both 
parties do not need to be on-line at the same time. This would facilitate the 
Electronic bulletin board availability to all vendors. Most private networks use 
X.400 as their E-mail standard and unless DOD adopts X.400 as their E-mail 
standard, problems with allowing messages from DOD’s proprietary protocols 
to X.400 will prevent widespread use. Private networks also use the OSI 
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standard X.500 to provide an electronic directory with electronic addresses of 
vendors and by function or business. DDN’s addressing scheme is archaic and 
does not interface with X.500. DOD’s Defense Automated Addressing System 
(DAAS) would provide minimum addressing services required until X.500 is 
adopted by DOD which would again eliminate another DOD proprietary 
system. DAAS is not scheduled to begin functioning completely until the year 
2000. 

Will DDN provide sufficient bandwidth to support EDI transactions? 
From Payne (1990) initial estimates based on 1988 volumes would produce 25 
gigabits of data per day from the procurement system alone. Transportation, 
fuels, etc., will also have the same amount of data. By 1992, at least one 
terrabit of data will be transmitted per day, if CALS data is shipped in an EDI 
envelope. Payne (1990) was very conservative in her estimate and also liberally 
assumes that very high speed lines (gigabits/second) will be available by 1995. 
A backbone infrastructure may approach these speeds but until the local 
subscriber loops upgrade to ISDN, it will not matter how high the speed is for 
the backbone because the chokepoint will be the local access line. Any thoughts 
about DDN being upgraded to a broadband network will be delayed because 
of budget constraints. Even a T-l network will not be sufficient to transmit 
thousands of terrabits of data. A compound CALS document containing 500 
engineering drawings with text, video and other graphics may contain nearly 
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one-half terrabit of data. It may not be uncommon to have electronic video 
teleconferences reviewing this type and volume of data by 1993. 

E. SUMMARY OF FINDINGS 

1. EC and Different Solicitation Methods 

Current EDI processing could support IFB for sealed bids because 
each item in the IFB has precise terms; part number, quantity, ship-to 
address, etc., but the ROI would be small because of relatively low volume of 
IFBs, according to Drake (1991). EC support for RFPs for competitive proposals 
are currently difficult because of the large volumes of text, technical data, and 
the lack of an architecture for multimedia data interchange required for video 
teleconferencing. BOA sole source orders and indefinite delivery contract orders 
could receive the best support from current EC and are very high volume 
(Drake, 1991). 

2. OSI Standards Are the Solution 
a. OSI 

OSI will make EC with large complex documents consisting of 
text, engineering specifications and drawing possible without regard to the 
platform and allow multimedia and hypermedia data interchange. CALS is 
developing data interchange formats and networks to exchange complex 
documents. Use of X.400 now will force compliance with OSI and provide 
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global interconnectivity and not just connectivity to US firms. Addresses in the 
X.500 directory would work with other OSI standards. 

6. FTAM/FTP Gateway 

FT AM (ISO 8571) is another published standard used by a few 
VANs and carriers to transfer files. It is an alternative to X.400 which is often 
the vehicle of choice for EDI, but in certain regions there is a tendency to use 
FTAM. For example, French banks chose to use FTAM for a major system 
because of electronic security issues in Europe. DOD uses FTP as standard for 
file transfer. An FTAM/FTP gateway would provide OSI compatibility to DOD 
at layer seven but this would require considerable overhead according to 
Henshall (1989). 

3. Digital Signatures 

Statutes and laws need to be revised to make the use of digital 
signatures acceptable in court should the need arise. NIST has adopted ANSI 
X9.9 to provide an effective means to authenticate the integrity of messages 
(InfoSec Conference, 1991). Operating systems, databases, application software, 
and access control software do not provide adequate data integrity to stand up 
in court. Crytographic authentication such as PKE is needed for most 
applications. 
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4. Electronic Contracting 

Users could negotiate contracts through the use of E-Mail by 
providing queries, messages, and discussions with archiving or electronic file 
cabinet. ASC X12 841 Specification/Technical Information transaction set 
combines graphics and text into a compound document. CCITT X.435 standard 
is designed for EDI using the X.400 Message Handling System. EDI 
transactions would be placed in an E-mail envelope to move large files. 
Reliance on DDN will place DOD further behind than it is now with its 
proprietary protocols. With the end of the Cold War, the role of DOD may 
shrink rapidly while the role of businesses will increase logarithmically. 
Vendors will have a difficult time trying to access DOD information if it 
remains in the DDN environment. It will be hard for the commerical 
community to interface with DOD if the IGP is not fielded until 1994 because 
industry is well on the way to OSI. X.400 is projected for beta testing by early 
1992. DOD cannot afford to wait until 1994 for development of the DOD 
Intelligent Gateway Processor (IGP). Commercial equivalents of the IGP exist 
today and should be used instead of developing an IGP in-house. 

5. Re-engineering 

DOD should re-engineer workflows before implementing EDI into 
existing systems, according to Strassman (1991). If DOD simply substitutes an 
electronic transaction for a paper one or a phone call, then EDI may cost the 
Government more than it does now in an automated paper based environment. 
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IV. OSI OPEN SYSTEMS INTERCONNECTION 



A. BACKGROUND 

1. Older Networks 

Some networks are interconnected physically but not designed to 
allow transparent exchange of data. Only basic physical connectivity between 
points existed a few years ago. Many examples of floppies being mailed around 
the country or world still exist today. The size of the floppy has changed and 
the amount of data on the floppy increased, but the fact that the mail 
transports the data remains. According to the CALS Implementation Plan 
(1987), DOD suggests keeping this modus operandi in place and not to fully 
pursue the electronic solution to transport multimedia and hypermedia data 
until after 1995. At that time, according to the Defense Message System Plan 
(1991),, the messaging part of DDN will be replaced by a much more robust 
system based on OSI standards. 

Even though two platforms may be wired together, the same 
communications protocol must be used to transmit data to each other. The 
growth of LANs in the late 1980s caused the need for interconnectivity of 
workgroups in the matrix organizations. Businesses and the DOD changed the 
way they do business from heirarchial organizations to matrix organizations 
which provide support horizontally rather than duplicate themselves vertically. 
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Even if these matrix departments added PCs, LANs, or mini-computers they 
still may require connectivity to a central computing center and to each other. 
In a geographically distributed network it may be difficult to funnel data 
through the central computer because of the amount and volume of traffic. 

2. Open Systems Networks 

Open systems networks are not only interconnected physically but 
also allow transparent exchange of data throughout the world. The primary 
goal of OSI is to provide interoperability between computers in different 
countries and corporations using a common communications infrastructure. 
OSI is a set of standards published by ISO and CCITT for data 
communications. Henshall (1989) discusses the ISO seven layer reference 
model. Multi- pi at form and multi-vendor environments in which all machines 
interoperate globally is the goal of OSI. 

Interoperable platforms can exchange data through a distributed 
application. For example, a user could send an E-mail message to a user on 
another network through a gateway. A client-server relationship allows 
cooperation among several connected computers. A user could access a 
distributed database or groupware. Groupware includes spreadsheeting, 
electronic meetings, multimedia messaging and compound documents, 
workflow automation, and mail-enabled applications. 

The movement to open systems began with proprietary protocols of 
single vendors such as IBM, DEC, Xerox, and HP. Next the DOD pioneered the 
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TCP/IP protocol suite. Multi-vendor support of TCP/IP produced the ability to 
send E-mail between different organizations by installing the TCP/IP software 
on routers. The E-mail standard for TCP/IP is SMTP which is very basic and 
lacks sophisticated transfer capability according to Delaura (1987). 

B. OSI REQUIREMENTS 

Many capabilities of OSI may require the use of an intelligent gateway 
which could exist on many different platforms. These capabilities include: 1) 
a layered peer-to-peer architecture with service infrastructures; 2) client-server 
applications using virtual resources; 3) multi-vendor and multi-platform; and 
4) being adaptable and seamless. Distributed networks may need intelligent 
gateways which have network control engines to manage the network. One of 
the main intents of OSI is to have different operating systems like DOS, 
Windows, OS/2, Macintosh, and Unix systems able to perform similar services 
with each other. The applications running on the different platforms should be 
integrated seamlessly. This research concentrates on the Message Handling 
System and its capability to support multimedia multi-platforms with text, 
facsimile, full motion video, and graphics. OSI should have the ability to grow 
to several million users in thousands of locations around the world. The 
Federal Government developed a subset of ISO standards selected by NIST to 
meet the needs of the government agencies called GOSIP. 
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C. OSI STANDARDS FOR MESSAGE HANDLING SYSTEM AND 
DIRECTORY SERVICES 

1. X.400 1984 and 1988 

a. Upper Layer Functions 

The application layer at the top of the OSI reference model in 
Henshall (1989) realizes the goal of OSI. The lower layers simply exist to 
provide support for the application layer. It makes services available to 
computer system users. The main functions of the seventh layer are file 
transfer access management and file directory operations; message handling; 
virtual terminal protocol; and job transfer, manipulation and remote job 
management (Henshall, 1989). 

b. X.400 Development 

Development of X.400 began in 1980 with the formation of the 
CCITT X.400 Protocol Committee. It took four years to complete the initial 
standards which were released in 1984 and as part of the Red Book. The first 
commercial products conforming to X.400 of 1984 appeared in 1986. According 
to Scott (1990), the initial products were primarily OEM source code. The 
committee produced a later version of the standards in 1988 which 
incorporated the message store, multimedia messaging, and security. Most 
X.400 1988 package products were released in early 1990. 
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c. 1984 Standards 



The 1984 standards included many basic features. According to 
Gifkins (1988), this version only met approximately 50 percent of the 
requirements in Logica’s Report to Vanguard on EDI and X.400. The basic 
features are: 

• Delivery notifications 

• Message tracing 

• Integrated messaging 

• Secure session establishment 

• Binary and encrypted data 

• Multi-destination delivery 

• Uniform, global addressing 

• Distribution lists 

• Grades of service 

• Deferred delivery 

d. 1988 Standards 

The 1988 standards added two additional features and 
introduced the concept of a message store which will be discussed later in this 
chapter (CCITT X.400, 1988). According to Gifkins (1988), this version met 
approximately 70 percent of the requirements in Logica’s Report to Vanguard 
on EDI and X.400. The two added features are: 
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• Generic advanced security 

• Latest delivery time 

e. X.400 Model 

The X.400 model contains user agents and message transfer 
service. The user agent defines the contents of the message which can be sent. 
The 1984 version was designed to send several different types of messages but 
only one type called interpersonal message (IPM) is specified in the 1984 
standard. IPM resembles a regular office memo (i.e., To:, From:, CC:, Subject:, 
Priority:, In reply to:, text, drawings, graphics, and voice) and is generally 
defined by the P2 protocol. P2 defines a header and a body. The header 
consists of addressing information. The body consists of one or more body parts 
which each have specific formats. The message transfer agent determines how 
to route messages from sender to receiver. The MTA provides for store and 
forward service as defined by the PI protocol. More than one user agent can 
use the services of a single message transfer agent. The MTA routes messages 
to the destination and delivers for their local user agents. MTA addressing 
uses a facility called originator/receiver name which is designed to provide all 
the necessary information to send a message internationally. 
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2. X.435 PEDI 



a. Development 

The CCITT recognized that EDI would require a basis for storing 
and forwarding messages around the world with grades of service and support 
of binary message contents. The committee therefore began development of 
X.435 in early 1988. Until 1988, EDI and X.400 standards pursued separate 
development. CCITT recently approved the 1990 X.435 standard in June 1991 
and, according to Eckerson (1991), industry analysts predict that the 1990 
standard will not be implemented until 1993. Vendors are in the process of 
implementing agreements on how to implement X.435 and should complete the 
agreements by the end of 1991. Eckerson (1991) states that it will take 6-9 
months to create beta versions to field in late 1992. Meanwhile, the DOD will 
be pursuing EDI over DDN through an intelligent gateway which is not 
scheduled for implementation until 1994 as stated in DLA (June, 1990). 
According to Sweeney (1991), the DOD does not plan to include X.400 in 
GOSIP until 1994. 

b. Features Added in the 1990 X.435 Standards 

(1) Advanced security specifically for EDI. Each part of the 
path of an EDI message can be protected by using encryption of data, 
verification of message sequence integrity, authentication of message originator 
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and receiver, non-repudiation, and authentication of the delivered message 
contents according to the CCITT X.435 (1991). 



(2) Message body parts. X.435 defines EDI messages to have 
at least one body part which is a place within the message where EDI 
interchange is carried. The first body part is always the part that contains EDI 
data. Subsequent body parts may carry different types of data (Figure 2). A 
CAD/CAM drawing, 1840A engineering graphic, PDES, or just text related to 
the EDI data could be contained in the other body parts. The alternative 
approach is similar to the CALS data in an 841 transaction proposed by 
Saltman (1990). It is more difficult for the communication software to perform 
the CAD/CAM processing because the X12 overhead data must be stripped 
away first before the binary data can be processed. 

(3) Cross-referencing table. The X.435 EDI message has a table 
which may allow several CAD/CAM drawings to be linked to a separate body 
part which contains the EDI interchange. Each page of the interchange may 
reference one of several CAD/CAM drawings using the table. 

( 4) Forwarding of EDI messages and EDI responsibility. A user 
may request notification on whether the recipient’s software accepted, refused, 
or forwarded the message he sent. The issuance of the notification report is a 
function of the UA. With this action, the software takes responsibility for the 
message and informs the users of who has responsibility at any specific time. 
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X.435 PEDI Message Structure 



Figure 2. X.435 PEDI Message Structure. 
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If the user has a central X.400 gateway through which all messages are 
screened and audited, the X.435 software examines the message and 
determines if it will be able to pass the message to the recipient’s application. 
A user from Japan may send an EDIFACT message to DOD which uses X12. 
The X.435 software then determines that the formats are incompatible and if 
the gateway does not contain multiple protocol converters will refuse to take 
EDI responsibility for the EDIFACT message and return a negative 
notification to the sender if requested. 

(5) EDI notifications. Three types of EDI notifications provide 
extra tracking capabilities beyond the simple notification of delivery. First, a 
positive EDI notification lets the sender know that the software accepted EDI 
responsibility for the message after examining it and determining that the 
interchange can be processed by the recipient’s application. Second, a negative 
EDI notification lets the sender know that the software refused EDI 
responsibility for the message after examining it and determining that the 
interchange cannot be processed by the recipient’s application. The third is a 
forwarding notification that tells the sender that the message was forwarded 
along with the EDI responsibility to another user. 

( 6) Message store. The combination of database functions such 
as queries, retrievals, deletions, searches, and sorts of a mailbox allow users 
to have the full functionality of an X.400 VAN or network without the 
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overhead of having to completely implement X.400 or X.435 on their computer. 
The message store assists the smaller EDI users because they do not have the 
computing resources or financial resources to fully implement X.435. Incoming 
messages would be placed into the user’s message store. When the user logs 
on, they can be alerted about new messages or other optional criteria that was 
selected. Other messages may also be retrieved from the mailbox according to 
these criterion. For example, the U.S. Army Tank Command may want to look 
at just EDI messages from General Motors for the month of July 1991 that 
contain invoicing information. 

3. X.500 Directory Service (ISO 9594 or CCITT X.500) 

Since the growth of networking started, there has been an increasing 
demand to maintain information about what kind of computers are on the 
network. The information includes application programs, people using the 
computer, and a physical address. E-mail directories provide look up services. 
DDN provides a Unix like command "Whois" to give directory type information 
on individuals using DDN. However, the DDN Network Information Center 
can only provide this information for DDN hosts only. Similar to most 
proprietary networks, these applications cannot be used on interconnected 
heterogenous networks. For example, AT&T Starmail and MCI Mail are 
interconnected and a user from one system may send mail to a user on the 
other system if he knows the address. However, if the address is unknown, a 
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Starmail user cannot check for an MCI E-mail address or vice versa and the 



Starmail user cannot send the E-mail to the MCI user. 

There is a great need for a globally interconnected directory which 
provides links to individuals, distribution lists, MTAs, application entities, and 
all UAs. Either the directory name or the originator/recepient address must be 
contained in the user’s message. The directory name will be more user friendly 
than the address which may change because of the physical configuration of 
the Message Handling System. A message with just a directory name will 
cause the Message Handling System to consult the directory to find the 
corresponding address. If the message contains the address, the Message 
Handling System will use the address provided to route the message. A user 
can use the directory service to verify a given address or find out additional 
information about a specific user. The address is an ordered list of attributes. 
It can be private or administration domain defined, a personal name, 
distribution list name, organizational unit name, and mneumonic addresses 
and called relative distinguished name. 

X.500 allows user friendly naming of objects and name-to-address 
mapping which supports the binding of objects and their locations. The 
directory is a specialized database supporting management and 
telecomm unicati on processes in a standardized format jointly developed by ISO 
and CCITT. The directory will be logically one directory but physically 
distributed with a unified name space. Directory user agents and system 



56 



agents will provide the application or human user with the ability to query the 
directory information database. This is done by using the directory access 
protocol between user agents and directory system protocol between system 
agents. 

4. Defense Message System (Program Plan) 

DOD tried to satisfy all messaging requirements in a single system 
procurement with the InterService/Agency Automated Message Processing 
Exchange (AMPE) in 1987. Do to severe budget constraints, a rapidly changing 
technology and new international standards, AMPE was cancelled and replaced 
with an evolutionary process to modernize the messaging system. AUTODIN 
and DDN form the baseline and will be replaced by off-the-shelf products 
conforming to international standards forming a distributed messaging system 
based upon X.400 and X.500. Phase 1 ends in 1994 and includes transitioning 
from TCP/IP to TP4 and from SMTP to X.400. AUTODIN traffic will switch to 
DDN and by the end of Phase Two, all Telecommunication Centers will begin 
phasing out. (Draft Defense Message System Plan, 1991) 

D. ANALYSIS 

1. Defense Message System 

An X.400 based solution is proposed in the Defense Message System 
Program Plan for DOD communication requirements. The schedules for this 
transition all indicate that the X.400 conversion will start in late 1991 for some 
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services and be completed by mid 1992. Based upon commericially available 
packages, this conversion will implement 1988 X.400 standards. However, 
when the 1990 X.435 standards become commercially available, it should be 
easy to upgrade because customers will have had experience with X.400 
products. 

Several corporations have developed platforms capable of performing 
at least the same requirements as the Lawrence Livermore National 
Laboratories Intelligent Gateway Processor. Off-the-shelf EDI translation 
software allows parameter changes which could accomodate DOD fields for 
processing. If DOD simply wants to automate existing processes then it would 
be extremely cost efficient to purchase a specific software package which is 
multi-platform capable on a PC. However, DOD should completely rethink how 
it performs its processes before implementing any EDI applications over X.435. 
Automating what a paper based system performs should be done after an 
analysis of how to electronically perform the work by rethinking the process. 

2. X.435 Versus Non-X.400 

There are several advantages of using X.435 versus non- X.400 based 
EDI according to Lyons (1991). First, X.400 allows audit trails to track each 
message through delivery notification and message tracing. The two types of 
delivery notifications are: 1) positive which tells whether the message was 
placed in the receiver’s mailbox successfully or 2) negative which also tells why 
the message could not be delivered. X.400 users can even find out if a message 
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was delivered to a receiver on a different network because the last X.400 



network generates the delivery notification. Each envelope documents the path 
that the message takes from the sender to the receiver. Each time the message 
transfers between X.400 networks, the envelope is updated with the name of 
the X.400 network through which it is passing. 

Second, EDI and E-mail may be integrated on one network instead 
of two because X.400 provides both services in the same protocol. A trading 
partner may use a VAN if he does not have X.400 capability. X.400 can even 
be used to send and receive facsimile messages. 

Third, since X.400 is an international standard, it is just as easy to 
send an E-mail message to a foreign receiver as it is to call them because most 
X.400 networks are international or interconnect to other foreign X.400 
networks. More and more EDI users who are part of a global enterprise are 
moving to X.400. 

Fourth, one security feature of X.400 establishes a secure session and 
the other allows the envelope to encrypt EDI data. Secure session 
establishment uses a logon ID and a password. Since binary data can be 
carried, users can transmit encrypted data which prevents the sender or 
receiver from reading that data. CAD/CAM data, spreadsheet files, faxed 
images also require binary data and can be encrypted. 

Fifth, like most E-mail systems X.400 allows a single message to go 
to multiple recipients with the use of distribution lists. These addresses are 
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unique in the entire world because they include user’s name, company, X.400 
VAN, and country. Neither EDIFACT nor X12 use a uniform global addressing 
scheme. The distribution list is created only once. 

Finally, unlike most E-mail systems X.400 offers three grades of 
service which determine how quickly a message is delivered and the cost of 
delivering the message. Many types of junk mail could be sent non-urgent. 
Some invoices or purchase orders may be sent normally and mistakes in 
payment may be sent urgently. A user can even set up a specified date and 
time of delivery several weeks into the future. 

E. SUMMARY 

Since X.400 can distinguish between the envelope and its contents, it is 
well suited for store-and-forward messaging such as EFT and EC/EDI. 

Since X.400 can support all earlier technologies such as E-mail, telex, 
facsimile, and exchange binary formatted data it is also well suited for CALS 
and other technical data interchange requirements. 

Commercially available software implementing the 1988 X.400 standards 
is available for intelligent gateways. These software packages could be used to 
handle most CALS requirements. Software implementing the 1990 X.435 
standards will be commercially available in less than one year. It could 
potentially benefit DOD to rapidly re-engineer processes. After completion of 
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the re-engineering new products could be available that will support 
multimedia and hypermedia interchange required in CALS and EC/EDI. 

A second option available to DOD is to use a VAN which will have the 
1990 standard implemented in mid 1992. Linking to a VAN which provides all 
the required services may be more economic. VANs have intelligent gateways 
and could be used as soon as parameters became established by DOD. 

With the adoption of X.435 in June 1991 as an international standard, the 
Message Handling System will become even more necessary to EDI and CALS 
users and should become the global standard for EDI messaging as more X.435 
products become available. According to Scott (1990), research indicates that 
the market for X.400 based gateways will grow by 60 percent over the next 
three years, reaching close to $100 million by 1993. Vendors that want to sell 
to a global market see X.400 as a platform with worldwide appeal. In 1992, 
after the European trade barriers will be lifted, open system standards will 
greatly increase trade in Europe. 
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V. MULTIMEDIA AND HYPERMEDIA DATA 
INTERCHANGE ARCHITECTURE 



A BACKGROUND 

The evolution of multimedia data involved three types of documents: 1) 
dumb documents; 2) compound documents; and 3) intelligent documents. The 
dumb document exists on only one type of media and must be manipulated in 
its entirety. The compound document combines different types of media and 
may be flexibly distributed and assembled. The intelligent document functions 
as a hypermedia system supported by expert systems to solve problems and to 
enhance user performance. 

1. Dumb Documents 

The dumb document can also be called the paper based document. It 
can be either in traditional hard copy conforming to standard formats or data 
item descriptions in a contract. The dumb document can be mailed through the 
postal system, Federal Expressed, etc., but always exists on permanent paper. 
Before the next step in the evolution of multimedia, technology developed to 
make images of the dumb document. Data processors became obsessed with 
image processing and the need to access archived documents. The microfiche 
technology used for over the past 20 years is gradually being replaced by 
optical storage technology. Large documents which are complex may be stored 
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more easily on an optical disk which may then be mailed. These large 
documents require lengthy transmission times across networks and in today’s 
networking environments have great difficulty traversing through gateways. 
Point to point transmissions may take hours depending on the length and 
complexity of the document. However, for relatively short page based 
documents, Group 4 raster graphics allow the use of telecommunications to 
make a facsimile of the document and send it electronically to another 
facsimile machine either from a stand alone computer or from a network 
facsimile server, or a stand alone fax which prints out a paper document. 

2. Compound Documents 

The compound document consists of data components of different 
types which a computer may process individually. Electronic scanners have 
added the dimension of converting handwritten text to word processed text. 
The word processing of text files began the evolution to hypertext. Standards 
such as SGML are in the process of evolving to guide the integration of 
multimedia with text to form compound documents. Plain text documents are 
rapidly becoming obsolete. Graphics files have several standards depending on 
the type of graphic used. CGM, IGES, and raster graphics discussed in 
Chapter II form the basis for the graphic metafiles required for compound 
documents. Database queries using SQL present views of objects. Audio/visual 
files are part of multimedia kits and business presentations in forms of 
animation, 3D, photos, combined with graphics and text. These integrated files 
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pose the biggest challenge to interchanging data in electronic commerce and 
CALS/CE. 

3. Intelligent Documents 

The intelligent type of document is a virtual document. It does not 
really exist. There is no need for archiving just for the information provided by 
virtual document. Certain applications may have predefined queries to 
multimedia databases which the virtual document may execute to obtain 
certain data from other multimedia databases. Other applications allow ad hoc 
queries to the multimedia databases. For example, an expert system conducts 
a hypersearch of several multimedia databases after a user asks a speech 
recognition neural network which in turn consults the expert system for 
information. Accessing hypermedia across networks will be difficult with low 
speed lines. Current solutions indicate that the hypermedia be physically 
transmitted through the mail or, if small enough, transmitted electronically as 
a binary file. X.400 allows the different data types to cross networks. 
Hypersearches of multimedia databases located in different networks will 
require high speed lines and X.400. After the system or user finishes with the 
information created by the hypersearch they can produce a new hypermedia 
document and store it by creating a virtual intelligent document that knows 
where to locate the information the next time it is needed. 
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B. REQUIREMENTS 



1. Hypermedia 

Hypermedia incorporates many complex information types that may 
exist on multiple platforms across a network. They are semantically 
interdependent and synchronized. Hypermedia allows cross-reference of all 
relevant works and lets the user browse to look for other relationships. They 
may contain full-motion including video and voice annotations. Thus, 
hypermedia interchange will require high resolution displays, high volume 
mass storage, and high speed data communications. No one specific document 
contains what the person wants but, after learning and getting new ideas from 
browsing around they may find what they want. Few corporations can afford 
hypermedia interchange at this level and must settle for much less. Currently, 
it is possible to send different types of information in one message using X.400 
but there are practical limits to the size of the files, according to Asgher (1991). 

2. Intelligent/Compound Documents 

Desktop publishing of forms represents over a third of all business 
documents, accounting for $6 billion and wasting nearly $2 billion of it, 
according to Skapinker (1991). Distribution, storage, and processing account 
for $100 billion because for every $1 spent on paper, it costs $60 to process it 
(Skapinker, 1991). Even though the forms are created, distributed, and filled 
electronically, businesses usually need a desktop publishing capability. There 



65 



is usually a need for signatures particularly in DOD. By signing the paper 
form, the form fillers take responsibility for the contents of the form. Once the 
form is filled out, the inputted data needs to be stored and the form used 
again. The forms must be indexed because these forms or images are dumb 
without tagging them with additional and searchable information. 

Compressing and decomposing large complex documents helps with 
routing but each end user must construct and reconstruct the images in a 
compatible way. If the users are on networks and are a part of a larger 
organization, its impact on the network is very significant. In fact, optical disk 
storage called jukeboxes are often used to handle the massive amounts of 
storage required. Unfortunately, jukeboxes, laser printers, faxes, scanners, and 
electronic tablets greatly clog up any current network which forces a reduction 
in the user/server ratio. OSI is attempting to define standards for the future 
business office to gain control of all the merging technologies in the intelligent 
document. 

3. Electronic Document Staffing 

Groupware allows computer-supported cooperative work whether 
people are seated next to each other or in different countries. For example, 
when the Army Combat Developers field a new piece of equipment, they may 
need software that manages the component parts of the big single document 
that comes from 26 different sites around the country. This software should 
allow one member to make comments on another’s document. The author could 
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review the comments and either accept or reject them before forwarding them 
to an approving authority for review and signature. 

4. Electronic File Cabinet 

Distributed multimedia database may involve many forms of 
information located in many locations. For example, offices and organizations 
keep standard file drawers, desk files, notes, reminders, cassette tapes, copies 
of faxes, pictures, videos, microfiche, compact discs, floppy disks, and even 
removeable hard drives. 

Cost estimates for manually filling a five drawer file cabinet, 
assuming $5 per piece of paper, range up to $50.00 per drawer of 1000 sheets. 
Maintaining that drawer could cost approximately 10% or $5.00 per year. The 
worst part is that approximately 5% or 50 documents will become misfiled and 
thus lost unless a complete search of each file is done at great time and 
expense which may double the cost of the piece of paper to $10 or more. The 
manager waiting for the misplaced documents may lose large contracts or 
potential profits. 

One cabinet may hold up to a tenth of a gigabit of data assuming 
that the average document size is 50 kilobits per page. Hard disks alone 
cannot handle this requirement but may be used in conjunction with optical 
technologies for indexing and temporarily retrieving working documents from 
the optical disk. WORM media automates and centralizes annotations, 
histories of the document, and proposed revisions to the document. Current 
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technology allows the creation of virtual WORM on a rewriteable drive. 
However, only a copy of a document on a WORM drive is considered a legal 
copy. Passing this information currently is done by the sneakernet. A good 
candidate for multimedia data interchange would be exchanging massive 
amounts of data over fiberoptic infrastructures such as FDDI. 

5. Document Imaging 

The central technology for a paperless office is document imaging. 
Paper documents are scanned into document image files which may be stored 
on an optical disk for retrieval, viewing, and printing. A typical industry model 
of a document image management system includes scanning and retrieval 
workstations connected to a laser printer, a document image processor server 
connected to a large optical jukebox and laser printer, workstations connected 
to laser printers, and a link between the corporate mainframe and the 
electronic archival system. A database holds the current day’s scanning 
activity. The master database holds all the documents in the system after the 
images are scanned, compressed by Group 4 standards and sent to the jukebox. 
The retrieval of a document allows keyword searches, multiple document 
displays, and the ability to zoom in on a particular area. 

One of the best examples of a paperless corporation is the United 
Services Automobile Association which provides insurance for active duty and 
retired officers of the armed forces and their dependents. According to Harvey 
(1991), over 1,000 graphics terminals connected to a large IBM 3090 MVS/EVA 
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system and separate dedicated IBM 4381s show the document, its history log 
and notes on file. The terminal allows the viewer to turn pages, zoom, 
rearrange pages, enter certain page numbers, and handle the document as 
though it was horizontal instead of 3D. Their storage system consists of five 
optical jukeboxes and 30 stand-alone optical WORM drives capable of 
containing over 2 terrabytes of data. (Harvey, 1991) 

6. Electronic Videoconferencing and Teleconferencing 

Sometimes instead of holding a meeting at one location, significant 
traveling expenses and time can be saved by reviewing the same documents 
in real time by holding a video teleconference. During a typical 
videoconference, paper documents are shown to the camera and seen in 
multiple locations. Future conferences should have the capabilities of having 
the identical screen at all locations with changes made to any screen seen 
simultaneously on all the terminals. The waste of time to postpone and 
reconvene a conference for lack of information that exists in a different format 
will be eliminated by gaining access to databases with the necessary 
information. 

C. CAN DATA COMMUNICATIONS BE BASED ON DDN? 

Most DDN backbone circuits between packet switch nodes are 56 Kilobits 
with a few T-l lines. The access lines to the terminal access controllers are 
normally 9,600 bits/second. DDN has limited connectivity to other networks. 
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For example, E-mail can be sent to an SNA network through a Softswitch 
gateway, but at a very slow rate. As discussed in Chapter III, the amount of 
data sent over the network will greatly increase with the use of compound 
documents. Compression techniques exist but the volume of messages and the 
size of graphics files, even when compressed, may be one megabit. Sending one 
engineering drawing could take at least two minutes if sent within DDN and 
could take all day if sent through the gateway depending on the queue of all 
other messages trying to get through the gateway to an SNA network. 
Organizations have reverted to asynchronous modem connections to transfer 
the files point to point when there is a network boundary to cross. X.400 will 
eliminate the chokepoint that exists when passing through a gateway to 
another network. If the workstation is on a highspeed LAN running at 10 
Megabits per second and the LAN is linked through an FDDI backbone or 
broadband backbone the throughput to another user could conceivably be 10 
Megabits per second which would transmit the engineering drawing in less 
than one second. DDN is incapable of attaining these high speeds. The upgrade 
to the Bolt, Baranek, and Neuman processors only made them capable of 
handling more ports at 56 Kilobits/second. 
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D. INTERCHANGE ARCHITECTURE FOR MULTIMEDIA 
AND HYPERMEDIA DATA 

1. EDI and X.400 for Multimedia Data Interchange 

In Chapter III, we discussed the requirement for including graphics 
along with text to form an electronic commerce transaction. For example, a 
picture with a Request For Proposal would not be be possible in a conventional 
EDI transaction because a conventional EDI transaction allows text only. Even 
worse, not all companies support EDI or are not fully EDI ready. It may take 
years to convert an entire business and all of its trading partners to EDI. Some 
data may have to exist in printable form for human intervention because some 
company will still rely on paper based systems. On the otherhand, X.400 can 
accept facsimile, E-mail, IGES, PDES, and other data types to transmit to the 
receiving partner’s mailbox. 

2. Hypermedia and Multimedia Interchange Architecture 

The telecommunication infrastructure for hypermedia and 
multimedia data interchange can best be served by ISDN and FDDI. The 
Government’s multi-billion dollar FTS 2000 contract supports ISDN and is 
available for use immediately. On top of this telecommunications 
infrastructure, the OSI protocol suite will be used including TP4, FTAM, 
X.400, X.500, and VT to form the infrastructure for the Defense Information 
System which includes the Defense Messaging System discussed in Chapter 
III. The most crucial part of the architecture (Figure 3) is the multimedia and 
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hypermedia data interchange standards. These standards include all the ones 
discussed in this thesis, especially Chapter I for CALS: CGM, SGML, IGES, 
PDES/STEP, and Group 4 Raster; and EC/EDI: EDIFACT, X12; and 
ODA/ODIF. The applications to use these standards include hypersearch and 
hypertext, groupware DSS, forms processing, multimedia databases, hand 
written character recognition, electronic performance support systems, 
electronic contracting, document image processing, logistics, and neural 
networks. Public key encryption and embedded encryption along with trusted 
databases and operating systems will allow the existence of multi-level security 
in this environment. 

3. Multi-level Security and Public Key Encryption 
a. Multi-level Security 

DOD could save a significant amount of money if classified 
documents could be electronically stored and transmitted between sites along 
with unclassified documents. Documents most often are unclassified with the 
exceptionof one or two pages which may contain confidential data, and one 
paragraph of secret data which makes the entire document secret. DOD has 
spent billions of dollars maintaining separate systems for the unclassified 
environment and the top secret and higher environment. Thousands of 
classified documents are still manually controlled and locked in large classified 
containers just as they were 50 years ago. Researchers and industry' have 
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attained multi-level security systems but the costs are still tremendous. The 
Worldwide Military Command and Control System installed many Gemini 
Computers running GEMSOS in front of large IBM mainframes each 
processing different types of classified and unclassified documents at a very 
significant cost compared to what most corporations could afford. 

Industry is developing trusted databases, trusted networks, and 
trusted computer security controls which will be present in the Secure Data 
Network System. Although still in the research and development phase, SDNS 
may become a great jump forward for security. Embedded encryption internal 
to PCs with automated public key administration will provide the basis for a 
totally new way of operating with classified data. 

b. Public Key Encryption 

An important part of the architecture is the ability to transmit 
encrypted data. According to Barker (1991), a hybrid of the secret key and 
public key techniques is recommended when secrecy, integrity, and 
authenticity are desired because secrecy can best be provided by using a secret 
key but authenticity is best provided using a public key. E-mail and EFT 
require non-repudiation of origin, which occurs when authenticity can be 
proven to a third party and to the receiver of the data. Presently organizations 
wish to use public key techniques for both non-repudiation of origin and for the 
distribution of secret keys. NIST is developing EDI data elements and 
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segments to allow the use of the public key for EDI, according to Barker 
( 1991 ). 

The public key algorithms provide non-repudiation of origin of 
the message by computing digital signatures. Digital signatures are a function 
of the signed data and the key used to sign the data. The private key 
calculates the digital signature and the public key verifies the digital 
signature. A signed message contains both the signed data and the digital 
signature. The originator of the message computes the digital signature by 
using his private key. The receiver of the message uses the public key to verify 
the signature. If the receiver verifies the signature then he knows that the 
sender of the message is really that person because no one else could have 
calculated the digital signature since only the sender knows the private key. 

The third party used to verify the digital signature is the 
certification authority. The certificates used by the authority contain the 
identity and the public key of the certificate’s owner and the digital signature 
on the data computed using the Certification Authority’s private key. The 
certification authority is trusted to not alter or falsify certificates exchanged 
between users. Each user gives his public key to the certification authority 
which gives its public key to each user. The certification authority then signs 
and issues a certificate to each user using its private key. 
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c. Neural Networks For Script Entry or Voice Entry 

Optical character recognition can make sense of text on the page 
with approximately 80% degree of accuracy, but near 100% accuracy can be 
expected with a neural network, according to the International Joint Neural 
Network Conference (1991). Hand-writing recognition lets you put annotations 
on documents and notes. OCR is best for printed text as long as the OCR 
system recognizes the dissimilar typefaces and vocabularies or two letters 
touching each other. Most U.S. companies cannot perform handwriting 
recognition except for hand printed block letters. However, Tazelaar (1991), 
states that a small Soviet company, ParaGraph, has a product called 
CalliGraph that dissects handwriting into component parts such as loops, 
curves, angles, and their sequence. The product is pen based using a graphics 
tablet. The components are compared to different letters made up of similar 
components and compared to a word list to find a valid word. As long as the 
word is on the list, CalliGraph will recognize the word. 

In the USAA example cited earlier under document imaging, the 
use of a neural net to fully automate the task of sorting documents by type will 
result in documents and faxes being routed to their destinations even faster 
and more economically because another human can be taken out of the 
workflow. As the network trains the accuracy will improve until no human 
intervention will be needed. Using neural networks for business document 
forms would be most benefical because using a process called forms subtraction 
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would eliminate the storage of billions of forms and just keep the data used 
with the form. According to Wright (1991), in the future, intelligent systems 
will be able to determine what is data and what is background on the form. 
Hand printed information or hard to recognize machine print will be separated 
from the background by the intelligent system. Fifth generation languages use 
natural language processing and sixth generation languages will use voice 
itself to execute commands and process data. Entry into forms databases by 
voice will greatly speed up forms entry. For example, an individual could call 
his bank and instead of waiting for the Voicemail selections and entering a 
number on the touchtone phone the individual may talk to the Voicemail just 
as if a human had been there processing data and keying it into a computer 
system. 

E. EXAMPLE PROJECTS 

During the course of the author’s research, several projects involving 
CALS/CE and EC/EDI were competing for funding from DLA. This research 
will examine three of those projects which demonstrate the need for the 
proposed interchange architecture. 

1. DLA X,400 On The IGP Platform 

DLA System Automation Center Central Design Activity in 
Columbus, Ohio, is working closely with the Retix Corp. to develop a 1984 
X.400 Implementation on the IGP platform. According to Asgher (1991), on 
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June 6, 1991, a successful test was conducted using a 386 PC running 
Interactive UNIX, AT&T 3B2/600G running AT&T UNIX, and a Gould X12 
running a LINX EDI program. The test demonstrated that an EDI transaction 
can be sent from a DOD environment with TCP/IP to the IGP and translated 
to an X.400 protocol as a user agent, then sent to a message transfer agent 386 
PC, then sent across an X.400 EDI VAN network to an ABC program which 
delivered the EDI message (Figure 4). The next phase in this project calls for 
eliminating or substituting for the 386 PC by running the LINX EDI program 
and the Message Handling System software on the 3B2 connecting it to the 
X.400 network. Asgher (1991) stated that X.400 will have a practical limit on 
the size of the file transmitted but that it will be very large and should handle 
most Government functions. White (1991) similarly stated that for the very 
large files exceeding 10 megabytes FTAM maybe better to use than X.400. 
Retix has based its Message Handling Software on Unix based platforms but 
will be porting it to DOS based platforms in the near future according to White 
(1991). The Gould minicomputers in DLA were procured in 1986 and are- 
obsolete. The AT&T 3B2 minicomputers in the Air Force and DLA were 
procured in 1989 and are two generations of hardware behind industry. The 
focus of this project for the future should be portability to any hardware 
platform to support the OSI environment. 
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DLA X.400 ON THE IGP PLATFORM PROOF OF CONCEPT 

AT&T 3B2 386 PC 




Figure 4. DLA X.400 on the IGP Platform Proof on Concept. 



2. National Procurement Pilot Project 

The second project this research discusses involved the U.S. Army 
Materiel Command Systems Integration and Management Activity in St. Louis, 
Missouri. The name of the project is National Procurement Pilot Project. 
According to Thrash (1991), the main thrusts are: integrate X12 850, 841, and 
8 58 transaction sets at the Tank Command with several commercial trading 
partners; perform a single MODELS file transfer and generate system modules 
for in/out MODELS processing; OSI architecture implementation on multi- 
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platforms; and overlay modular EDI as Procurement Early Development 
System is implemented. The software platform at DLA Central Design Activity, 
Columbus, Ohio will be a primary consideration because it has already been 
conceptually proven and is OSI based. The availability of the Lawrence 
Livermore National Laboratories IGP and its lengthy development schedule 
would essentially delay this project for an unacceptable period. The schedule 
given by DLA for the development of the Lawrence Livermore National 
Laboratories IGP shows that it will be three more years until it should be 
ready for fielding. 

3. Highly Automated Office 

The final project discussed contains most of the multimedia and 
hypermedia issues this research presented. The U.S. Army Corps of Engineers 
(USACE) proposes a project entitled "A Proposal to Enhance Electronic 
Commerce Through Creation of an Automated Office Environment." According 
to Tisel (1991) the project keys on an application called Knowledge Worker 
System (KWS) which will operate under Windows. KWS is an electronic 
performance system support groupware product that is based on expert 
systems, multimedia databases, and hypertext through dynamic data 
exchange. KWS has a unified interface that integrates the whole set of 
productivity tools used by knowledge workers. The entire workflow will be re- 
engineered and coordinated throughout the organization by automating access 
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and retrieval of multimedia information through a distributed environment 
and EDI. 

F. IMPLICATIONS 

The long awaited paperless office may be attainable by the year 2000 in 
DOD if the proposed interchange architecture is adopted. If technological 
breakthroughs occur at the same rapid pace as in the 1980s, and 
standardization through open systems accelerates, the goal of completely 
changing the way we do business or the paperless office may finally become 
reality. New products called multimedia development kits or hyperwriters will 
become widely available. For example, Microsoft will use multimedia PCs and 
Windows with multimedia to provide a platform for developing multimedia 
applications and title developers. Several functions can occur such as recording 
voice and music, creating training manuals online, adding voice annotation 
features to a business application, and editing color bitmaps and palettes. The 
application programming interface allows the applications to perform even 
more functions such as waveform audio recording and playback, musical 
instrument digital interface music played on internal or external synthesizers, 
media control interface for controlling peripherals like videodisc and videotape 
players, animation playback, managing multimedia data, and high resolution 
timer services. The Viewer and Viewer Author’s Toolkit let the developer 
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prepare text, images, audio, hyperjump from text to graphics, search hypertext 
documents, and hyperjump from bitmap images to text. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

Advances in interoperability and connectivity have changed our way of 
doing business by going from islands of automation to application-to- 
application processing. Physical connectivity and file transfers between 
computers are no longer enough to satisfy the needs of the ever growing 
number of users and organizations. This will provide a foundation upon which 
TQM of IS is implemented. TQM of IS dictates that technology must be applied 
to the workflow not the workflow to the technology. The OSI architecture and 
standards allow applications to interface seamlessly across homogenous 
networks. The use of the interchange architecture proposed by this research 
will allow multimedia and hypermedia applications to seamlessly interface 
across heterogeneous networks worldwide. 

B. RECOMMENDATIONS 

Adoption of the standard interchange architecture for multimedia and 
hypermedia data is the best strategy to follow to successfully implement 
EC/EDI and CALS/CE. Anything short of using OSI protocols from the start 
will be a waste of dollars and place DOD further behind industry. All on going 
projects should be examined for use of OSI protocols and, if they cannot use 
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them within a short period, should be reconsidered. All projects should be re- 
engineered first before trying to apply technology to the solution. The DOD 
suite of protocols should no longer be supported and the transition to GOSIP 
should take place as soon as possible. Industry has made the switch to OSI 
and unless the Government follows quickly they will fall further behind. DOD 
cannot afford to wait for the IGP solution to add X.400 in 1994 to a specific 
platform. The best option currently is to use 1988 X.400 VANs which support 
EDI from various PC platforms. Continuing support for TCP/IP and 
SMTP/X.400 gateways will only prolong the use of a proprietary protocol and 
delay the transition to OSI. DCA should grant waivers to any organization 
needing EC/EDI and let them pay for a dedicated leased high speed access line 
to an X.400 VAN. 

C. RECOMMENDATIONS FOR FUTURE RESEARCH 

1. Electronic Performance Support System 

The next logical step beyond the interchange architecture for 
multimedia and hypermedia is to develop an information software system to 
use the capabilities provided by the architecture. The EPSS can harness high 
powered workstations, super mainframes, touchscreens, multimedia platforms, 
object oriented platforms, authoring systems, databases which stores data, 
various kinds of text, scanned photographs, etc. Hypertext, expert systems, and 
multimedia integration can provide users with immediate access to 
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information, advice, guidance or assistance, training, and other tools using just 
the computer without any other human assistance. Smart systems that are 
problem solvers for users may provide the return on investment that 
executives have been yearning for and hoping that information systems would 
have provided long ago. EPSS demonstrates the TQM of information systems. 

2. Object Oriented Programming 

The hypermedia interchange architecture allows the user to function 
at the application level without being concerned with the lower level functions, 
standards, and telecommunications infrastructures. This architecture may 
provide the necessary infrastructures to facilitate true object oriented 
programming in application development. 

The object oriented document approach uses object linking and 
embedding for documents allowing data type independence. 
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APPENDIX: X12 SUBCOMMITTEES 



1. X12C Communications & Controls 

2. X12D Education & Implementation 

3. X12E Product Data 

4. X12F Finance 

5. X12G Government 

6. X12H Materials Management 

7. X12I Transportation 

8. X12J Technical Assessment 

9. X12K Purchasing 

10. X12L Industry Standards Transition 

11. X12M Distribution & Warehousing 
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